-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use new private endpoint connections API #183
Conversation
b75ef36
to
08138d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes look good to me. I'm slightly confused about the state of the example here:
https://github.com/cockroachdb/terraform-provider-cockroach/blob/main/examples/resources/cockroach_aws_private_endpoint_connection/cockroach_aws_private_endpoint_connection.tf
I actually have an outstanding PR to rename it anyways but perhaps the contents should be update as part of this to reflect the correct usage.
Along similar lines, I'm wondering if there is any necessary migration as part of this or period where we need to keep a deprecated resource name around?
ack. will update
Fortunately, we're not deprecating any TF fields as part of this change. |
08138d7
to
3850859
Compare
Acceptance test: had do manually change some code to make this work. There's no straight-forward way to automatically test Private endpoint connection creation bc the client needs to create the endpoint out of band before calling the API. I created the endpoint manually and hardcoded the endpoint id into the test.
|
Actually I was able to add a fixture for the serverless test so it runs with the acceptance tests. It will reuse the real, existing endpoint id. |
3850859
to
f96fd7d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I had a few concerns. Left some comments in there.
@@ -38,17 +38,18 @@ func TestAccDedicatedPrivateEndpointConnectionResource(t *testing.T) { | |||
} | |||
|
|||
func TestAccServerlessPrivateEndpointConnectionResource(t *testing.T) { | |||
t.Skip("Skipping until we can either integrate the AWS provider " + | |||
"or import a permanent test fixture.") | |||
// This test relies on a pre-created private endpoint created via the AWS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels a little fragile to me. Do we have anything protecting it from being removed? Many teams won't have the perms to fix it if it breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't think of a way to make it "unfragile", except actually allocating an AWS account for TF testing, creating an AWS service account, creating an API key for the account, using the AWS SDK to create and delete the private endpoint connection on each test run, running the tests with the AWS API key. We'd also need to figure out a way to store AWS API Key so all engineers have access. Maybe vault, but then the TF tests would have a vault dep. I don't think it's a viable approach atm, too much hassle.
I know it's janky but I think the approach in this PR could get us working acceptance tests for a year since the staging Host clusters will prob not be re-created any time soon. It will break eventually and it be annoying to fix but IMO the future pain is worth having coverage. If you feel differently, I can leave the acceptance test as skipped and punt on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm actually I'm going to leave this test as skipped since the endpointId only works for staging. Any acceptance test ran against any other env will fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to make it conditional on the env? Or maybe we can add instructions for running the test in staging?
@@ -238,7 +231,7 @@ resource "cockroach_private_endpoint_services" "services" { | |||
|
|||
resource "cockroach_private_endpoint_connection" "connection" { | |||
cluster_id = cockroach_cluster.dedicated.id | |||
endpoint_id = "endpoint-id" | |||
endpoint_id = "vpce-0011573c1fa6afa3d" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather than hard coding this id everywhere, is it possible to use a datasource to fetch the endpoint using something else like name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to use a datasource to fetch the endpoint using something else like name?
To fetch from AWS? We'd need AWS creds and we'd need to figure out a way to share the AWS API key across CC eng. Also, the endpoint is only uniquely identified by ID, so we'd still need to store the endpointId somewhere.
f96fd7d
to
60055fc
Compare
60055fc
to
faccbd4
Compare
Previously, the private_endpoint_connection resource only supported AWS private link connections. This commit updates the provider code to use the new CC API Private Endpoint Connections methods. These cloud-neutral methods will work for all cloud providers and cluster types, except Serverless clusters on Azure as that configuration is not yet supported.
faccbd4
to
88b879c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Commit checklist
make generate
)